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Abstract 


Currently, OSPF for IPv6é (OSPFv3) uses IPsec as the only mechanism 
for authenticating protocol packets. This behavior is different from 
authentication mechanisms present in other routing protocols (OSPFv2, 
Intermediate System to Intermediate System (IS-IS), RIP, and Routing 
Information Protocol Next Generation (RIPng)). In some environments, 
it has been found that IPsec is difficult to configure and maintain 
and thus cannot be used. This document defines an alternative 
mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does 
not depend only upon IPsec for authentication. 


The OSPFv3 Authentication Trailer was originally defined in RFC 6506. 
This document obsoletes RFC 6506 by providing a revised definition, 
including clarifications and refinements of the procedures. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7166. 
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Copyright Notice 


Copyright (c) 2014 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF 
for IPv6 (OSPFv3) [RFC5340] does not include the AuType and 
Authentication fields in its headers for authenticating protocol 
packets. Instead, OSPFv3 relies on the IPsec protocols 
Authentication Header (AH) [RFC4302] and Encapsulating Security 
Payload (ESP) [RFC4303] to provide integrity, authentication, and/or 
confidentiality. 


[RFC4552] describes how IPv6 AH and ESP extension headers can be used 
to provide authentication and/or confidentiality to OSPFv3. 


However, there are some environments, e.g., Mobile Ad Hoc Networks 
(MANETs), where IPsec is difficult to configure and maintain; this 
mechanism cannot be used in such environments. 


[RFC4552] discusses, at length, the reasoning behind using manually 
configured keys, rather than some automated key management protocol 
such as Internet Key Exchange version 2 (IKEv2) [RFC5996]. The 
primary problem is the lack of a suitable key management mechanism, 
as OSPFv3 adjacencies are formed on a one-to-many basis and most key 
management mechanisms are designed for a one-to-one communication 
model. This forces the system administrator to use manually 
configured Security Associations (SAs) and cryptographic keys to 
provide the authentication and, if desired, confidentiality services. 


Regarding replay protection, [RFC4552] states that: 


Since it is not possible using the current standards to provide 
complete replay protection while using manual keying, the proposed 
solution will not provide protection against replay attacks. 


Since there is no replay protection provided, there are a number of 
vulnerabilities in OSPFv3 that have been discussed in [RFC6039]. 


While techniques exist to identify ESP-NULL packets [RFC5879], these 
techniques are generally not implemented in the data planes of OSPFv3 
routers. This makes it very difficult for implementations to examine 
OSPFv3 packets and prioritize certain OSPFv3 packet types, e.g., 
Hello packets, over the other types. 


This document defines a mechanism that works similarly to OSPFv2 
[RFC5709] to provide authentication to OSPFv3 packets and solves the 
problems related to replay protection and deterministically 
disambiguating different OSPFv3 packets as described above. 
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This document adds support for the Secure Hash Algorithms (SHAs) 
defined in the US NIST Secure Hash Standard (SHS), which is specified 
by NIST FIPS 180-4. [FIPS-180-4] includes SHA-1, SHA-224, SHA-256, 
SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) 
authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used. 


1.1. Requirements 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


1.2. Summary of Changes from RFC 6506 
This document includes the following changes from RFC 6506 [RFC6506]: 


1. Sections 2.2 and 4.2 explicitly state that the Link-Local 
Signaling (LLS) block checksum calculation is omitted when an 
OSPFv3 Authentication Trailer is used for OSPFv3 authentication. 
The LLS data block is included in the authentication digest 
calculation, and computation of a checksum is unnecessary. 
Clarification of this issue was documented in an erratum. 


2. Section 3 previously recommended usage of an expired key for 
transmitted OSPFv3 packets when no valid keys existed. This 
statement has been removed. 


3. Section 4.5 includes a correction to the key preparation to use 
the Protocol-Specific Authentication Key (Ks) rather than the 
Authentication Key (K) as the initial key (Ko). This problem was 
also documented in an erratum. 


4. Section 4.5 also includes a discussion of the choice of key length 
to be the hash length (L) rather than the block size (B). The 
discussion of this choice was included to clarify an issue raised 
in a rejected erratum. 


5. Sections 4.1 and 4.6 indicate that sequence number checking is 
dependent on OSPFv3 packet type in order to account for packet 
prioritization as specified in [RFC4222]. This was an omission 
from RFC 6506 [RFC6506]. 


6. Section 4.6 explicitly states that OSPFv3 packets with a 
nonexistent or expired Security Association (SA) will be dropped. 


7. Section 5 includes guidance on the precise actions required for an 
OSPFv3 router providing a backward-compatible transition mode. 
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2s 


2: 


Proposed Solution 


To perform non-IPsec Cryptographic Authentication, OSPFv3 routers 
append a special data block, henceforth referred to as the 
Authentication Trailer, to the end of the OSPFv3 packets. The length 
of the Authentication Trailer is not included in the length of the 
OSPFv3 packet but is included in the IPv6 payload length, as shown in 
Figure 1. 


+--------------------- + —- -- +---------------------- + 
| IPv6 Payload Length | “ a | IPv6 Payload Length | 
| PL = OL + LL li | | PL = OL + LL + AL | 
| |v vo | | 
4+--------------------- + —- -- 0 4---------------------- + 
| OSPFv3 Header | S = | OSPFv3 Header 
Length = OL Length = OL 
| OSPFv3 | 
| Din ee p80 a ea R a | | Packet | | E E EE S E | 
| | | Length | | | 
| OSPFv3 Packet | | | | OSPFv3 Packet 
| |v vo | | 
4--------------------- + —- -- 0 4---------------------- + 
| ee ‘aan | 
| Optional LLS | | LLS Data | | Optional LLS 
| LL = LLS Data | | Block | | LL = LLS Data 
| Block Length | v Length v | Block Length 
4+--------------------- + -- -- 0 4---------------------- + 
AL = PL - (OL + LL) | Authentication 
| | AL = Fixed Trailer + | 
voo] Digest Length ć | 
-- 0 4---------------------- + 


Figure 1: Authentication Trailer in OSPFv3 


The presence of the Link-Local Signaling (LLS) [RFC5613] block is 
determined by the L-bit setting in the OSPFv3 Options field in OSPFv3 
Hello and Database Description packets. If present, the LLS data 
block is included along with the OSPFv3 packet in the Cryptographic 
Authentication computation. 


1. AT-Bit in Options Field 


RFC 6506 introduced the AT-bit ("AT" stands for "Authentication 
Trailer") into the OSPFv3 Options field. OSPFv3 routers MUST set the 
AT-bit in OSPFv3 Hello and Database Description packets to indicate 
that all the packets on this link will include an Authentication 
Trailer. For OSPFv3 Hello and Database Description packets, the 
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AT-bit indicates that the AT is present. For other OSPFv3 packet 
types, the OSPFv3 AT-bit setting from the OSPFv3 Hello/Database 
Description setting is preserved in the OSPFv3 neighbor data 
structure. OSPFv3 packet types that don’t include an OSPFv3 Options 
field will use the setting from the neighbor data structure to 
determine whether or not the AT is expected. 


0 1 2 
01234567890123 45 678 901 2 3 


Figure 2: OSPFv3 Options Field 


The AT-bit, as shown in the figure above, MUST be set in all OSPFv3 
Hello and Database Description packets that contain an Authentication 
Trailer. 


2.2. Basic Operation 


The procedure followed for computing the Authentication Trailer is 
much the same as those described in [RFC5709] and [RFC2328]. One 
difference is that the LLS data block, if present, is included in the 
Cryptographic Authentication computation. 


The way the authentication data is carried in the Authentication 
Trailer is very similar to how it is done in the case of [RFC2328]. 
The only difference between the OSPFv2 Authentication Trailer and the 
OSPFv3 Authentication Trailer is that information in addition to the 
message digest is included. The additional information in the OSPFv3 
Authentication Trailer is included in the message digest computation 
and is therefore protected by OSPFv3 Cryptographic Authentication as 
described herein. 


Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and 
Link-Local Signaling Cryptographic Authentication [RFC5613], checksum 
calculation and verification are omitted for both the OSPFv3 header 
checksum and the LLS data block when the OSPFv3 authentication 
mechanism described in this specification is used. 


2.3. IPv6 Source Address Protection 


While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, 
the IPv6 source address is learned from OSPFv3 Hello packets and 
copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is 
susceptible to Man-in-the-Middle attacks where the IPv6 source 
address is modified. To thwart such attacks, the IPv6 source address 
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will be included in the message digest calculation and protected by 
OSPFv3 authentication. Refer to Section 4.5 for details. This is 
different than the procedure specified in [RFC5709] but consistent 
with [MANUAL-KEY]. 

3. OSPFv3 Security Association 


An OSPFv3 Security Association (SA) contains a set of parameters 
shared between any two legitimate OSPFv3 speakers. 


Parameters associated with an OSPFv3 SA are as follows: 


o Security Association Identifier (SA ID) 


This is a 16-bit unsigned integer used to uniquely identify an 
OSPFv3 SA, as manually configured by the network operator. 


The receiver determines the active SA by looking at the SA ID 
field in the incoming protocol packet. 


The sender, based on the active configuration, selects an SA to 
use and puts the correct Key ID value associated with the SA in 
the OSPFv3 protocol packet. If multiple valid and active OSPFv3 
SAs exist for a given interface, the sender may use any of those 
SAs to protect the packet. 


Using SA IDs makes changing keys while maintaining protocol 
operation convenient. Each SA ID specifies two independent parts: 
the authentication algorithm and the Authentication Key, as 
explained below. 


Normally, an implementation would allow the network operator to 
configure a set of keys in a key chain, with each key in the chain 
having a fixed lifetime. The actual operation of these mechanisms 
is outside the scope of this document. 


Note that each SA ID can indicate a key with a different 
authentication algorithm. This allows the introduction of new 
authentication mechanisms without disrupting existing OSPFv3 
adjacencies. 


o Authentication Algorithm 


This signifies the authentication algorithm to be used with this 
OSPFv3 SA. This information is never sent in clear text over the 
wire. Because this information is not sent on the wire, the 
implementer chooses an implementation-specific representation for 
this information. 
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Currently, the following algorithms are supported: 
*  HMAC-SHA-1, 

*  HMAC-SHA-256, 

*  HMAC-SHA-384, and 

*  HMAC-SHA-512. 


o Authentication Key 


This value denotes the Cryptographic Authentication Key associated 
with this OSPFv3 SA. The length of this key is variable and 
depends upon the authentication algorithm specified by the 

OSPFv3 SA. 


o KeyStartAccept 


This value indicates the time that this OSPFv3 router will accept 
packets that have been created with this OSPFv3 SA. 


o KeyStartGenerate 


This value indicates the time that this OSPFv3 router will begin 
using this OSPFv3 SA for OSPFv3 packet generation. 


o KeyStopGenerate 


This value indicates the time that this OSPFv3 router will stop 
using this OSPFv3 SA for OSPFv3 packet generation. 


o KeyStopAccept 


This value indicates the time that this OSPFv3 router will stop 
accepting packets generated with this OSPFv3 SA. 


In order to achieve smooth key transition, KeyStartAccept SHOULD 
be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less 
than KeyStopAccept. If KeyStartGenerate or KeyStartAccept is left 
unspecified, the time will default to 0, and the key will be used 
immediately. If KeyStopGenerate or KeyStopAccept is left 
unspecified, the time will default to infinity, and the key’s 
lifetime will be infinite. When a new key replaces an old key, 
the KeyStartGenerate time for the new key MUST be less than or 
equal to the KeyStopGenerate time of the old key. 


Bhatia, et al. Standards Track [Page 8] 


RFC 7166 Authentication Trailer for OSPFv3 March 2014 


Key storage SHOULD persist across a system restart, warm or cold, 
to avoid operational issues. In the event that the last key 
associated with an interface expires, the network operator SHOULD 
be notified, and the OSPFv3 packet MUST NOT be transmitted 
unauthenticated. 


4. Authentication Procedure 
4.1. Authentication Trailer 


The Authentication Trailer that is appended to the OSPFv3 protocol 
packet is described below: 


0 1 2 3 
012345678901234567890123456789 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Authentication Type | Auth Data Len 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ++ 
| Reserved | Security Association ID 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Cryptographic Sequence Number (High-Order 32 Bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Cryptographic Sequence Number (Low-Order 32 Bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 

| 


Authentication Data (Variable) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Figure 3: Authentication Trailer Format 
The various fields in the Authentication Trailer are as follows: 
o Authentication Type 


This 16-bit field identifies the type of authentication. The 
following values are defined in this specification: 


0 - Reserved. 
1 - HMAC Cryptographic Authentication as described herein. 


o Auth Data Len 
This is the length in octets of the Authentication Trailer (AT), 


including both the 16-octet fixed header and the variable-length 
message digest. 
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o Reserved 


This field is reserved. It SHOULD be set to 0 when sending 
protocol packets and MUST be ignored when receiving protocol 
packets. 


o Security Association Identifier (SA ID) 


This 16-bit field maps to the authentication algorithm and the 
secret key used to create the message digest appended to the 
OSPFv3 protocol packet. 


Though the SA ID implies the algorithm, the HMAC output size 
should not be used by implementers as an implicit hint, because 
additional algorithms may be defined in the future that have the 
same output size. 


o Cryptographic Sequence Number 


This is a 64-bit strictly increasing sequence number that is used 
to guard against replay attacks. The 64-bit sequence number MUST 
be incremented for every OSPFv3 packet sent by the OSPFv3 router. 
Upon reception, the sequence number MUST be greater than the 
sequence number in the last accepted OSPFv3 packet of the same 
OSPFv3 packet type from the sending OSPFv3 neighbor. Otherwise, 
the OSPFv3 packet is considered a replayed packet and dropped. 
OSPFv3 packets of different types may arrive out of order if they 
are prioritized as recommended in [RFC4222]. 


OSPFv3 routers implementing this specification MUST use available 
mechanisms to preserve the sequence number’s strictly increasing 
property for the deployed life of the OSPFv3 router (including 
cold restarts). One mechanism for accomplishing this would be to 
use the high-order 32 bits of the sequence number as a wrap/boot 
count that is incremented anytime the OSPFv3 router loses its 
sequence number state. Sequence number wrap is described in 
Section 4.1.1. 


o Authentication Data 


This field contains variable data that is carrying the digest for 
the protocol packet and optional LLS data block. 
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4.1.1. Sequence Number Wrap 


When incrementing the sequence number for each transmitted OSPFv3 
packet, the sequence number should be treated as an unsigned 64-bit 
value. If the lower-order 32-bit value wraps, the higher-order 
32-bit value should be incremented and saved in non-volatile storage. 
If by some chance the OSPFv3 router is deployed long enough that 
there is a possibility that the 64-bit sequence number may wrap, all 
keys, independent of their key distribution mechanism, MUST be reset 
to avoid the possibility of replay attacks. Once the keys have been 
changed, the higher-order sequence number can be reset to 0 and saved 
to non-volatile storage. 


4.2. OSPFv3 Header Checksum and LLS Data Block Checksum 


Both the checksum calculation and verification are omitted for the 
OSPFv3 header checksum and the LLS data block checksum [RFC5613] when 
the OSPFv3 authentication mechanism described in this specification 
is used. This implies the following: 


o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum 
computation is omitted, and the OSPFv3 header checksum SHOULD be 
set to 0 prior to computation of the OSPFv3 Authentication Trailer 
message digest. 


o For OSPFv3 packets including an LLS data block to be transmitted, 
the OSPFv3 LLS data block checksum computation is omitted, and the 
OSPFv3 LLS data block checksum SHOULD be set to 0 prior to 
computation of the OSPFv3 Authentication Trailer message digest. 


o For received OSPFv3 packets including an OSPFv3 Authentication 
Trailer, OSPFv3 header checksum verification MUST be omitted. 
However, if the OSPFv3 packet does include a non-zero OSPFv3 
header checksum, it will not be modified by the receiver and will 
simply be included in the OSPFv3 Authentication Trailer message 
digest verification. 


o For received OSPFv3 packets including an LLS data block and OSPFv3 
Authentication Trailer, LLS data block checksum verification MUST 
be omitted. However, if the OSPFv3 packet does include an LLS 
data block with a non-zero checksum, it will not be modified by 
the receiver and will simply be included in the OSPFv3 
Authentication Trailer message digest verification. 
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4.3. Cryptographic Authentication Procedure 


As noted earlier, the SA ID maps to the authentication algorithm and 
the secret key used to generate and verify the message digest. This 
specification discusses the computation of OSPFv3 Cryptographic 
Authentication data when any of the NIST SHS family of algorithms is 
used in the Hashed Message Authentication Code (HMAC) mode. 


The currently valid algorithms (including mode) for OSPFv3 
Cryptographic Authentication include: 


o HMAC-SHA-1, 

o HMAC-SHA-256, 

o HMAC-SHA-384, and 

o HMAC-SHA-512. 

Of the above, implementations of this specification MUST include 
support for at least HMAC-SHA-256 and SHOULD include support for 
HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and 
HMAC-SHA-512. 


Implementations of this specification MUST use HMAC-SHA-256 as the 
default authentication algorithm. 


4.4. Cross-Protocol Attack Mitigation 
In order to prevent cross-protocol replay attacks for protocols 
sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID 
is appended to the Authentication Key prior to use. Other protocols 
using Cryptographic Authentication as specified herein MUST similarly 
append their respective Cryptographic Protocol IDs to their keys in 
this step. Refer to the IANA Considerations (Section 7). 

4.5. Cryptographic Aspects 


In the algorithm description below, the following nomenclature, which 
is consistent with [FIPS-198-1], is used: 


H is the specific hashing algorithm (e.g., SHA-256). 
K is the Authentication Key from the OSPFv3 Security Association. 
Ks is a Protocol-Specific Authentication Key obtained by appending 


Authentication Key (K) with the two-octet OSPFv3 Cryptographic 
Protocol ID. 
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Ko is the cryptographic key used with the hash algorithm. 


B is the block size of H, measured in octets rather than bits. Note 
that B is the internal block size, not the hash size. 


For SHA-1 and SHA-256: == 64 
For SHA-384 and SHA-512: B == 128 
L is the length of the hash, measured in octets rather than bits. 
XOR is the exclusive-or operation. 
Opad is the hexadecimal value 0x5c repeated B times. 
Ipad is the hexadecimal value 0x36 repeated B times. 


Apad is a value that is the same length as the hash output or message 
digest. The first 16 octets contain the IPv6 source address followed 
by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This 
implies that hash output is always a length of at least 16 octets. 


1. Preparation of the Key 


The OSPFv3 Cryptographic Protocol ID is appended to the 
Authentication Key (K), yielding a Protocol-Specific 
Authentication Key (Ks). In this application, Ko is always 

L octets long. While [RFC2104] supports a key that is up to 

B octets long, this application uses L as the Ks length consistent 
with [RFC4822], [RFC5310], and [RFC5709]. According to 
[FIPS-198-1], Section 3, keys greater than L octets do not 
Significantly increase the function strength. Ks is computed as 


follows: 
If Ks is L octets long, then Ko is equal to Ks. If Ks is more 
than L octets long, then Ko is set to H(Ks). If Ks is less 


than L octets long, then Ko is set to the value of Ks, with 
zeros appended to the end of Ks such that Ko is L octets long. 


2. First-Hash 
First, the OSPFv3 packet’s Authentication Data field in the 
Authentication Trailer is filled with the value Apad. This is 


very Similar to the appendage described in [RFC2328], 
Appendix D.4.3, Items (6) (a) and (6) (d)). 
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Then, a First-Hash, also known as the inner hash, is computed as 
follows: 


First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet) ) 


When XORing Ko and Ipad, Ko will be padded with zeros to the 
length of Ipad. 


Implementation Note: The First-Hash above includes the 
Authentication Trailer as well as the OSPFv3 packet as per 
[RFC2328], Appendix D.4.3, and the LLS data block, if present 
[RFC5613]. 


The definition of Apad (above) ensures that it is always the same 
length as the hash output. This is consistent with RFC 2328. 
Note that the "(OSPFv3 Packet)" referenced in the First-—Hash 
function above includes both the optional LLS data block and the 
OSPFv3 Authentication Trailer. 


The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; 
for SHA-384, 48 octets; and for SHA-512, 64 octets. 


3. Second-Hash 


Then a Second-Hash, also known as the outer hash, is computed as 
follows: 


Second-Hash = H(Ko XOR Opad || First-Hash) 


When XORing Ko and Opad, Ko will be padded with zeros to the 
length of Opad. 


4. Result 


The resulting Second-Hash becomes the authentication data that is 
sent in the Authentication Trailer of the OSPFv3 packet. The 
length of the authentication data is always identical to the 
message digest size of the specific hash function H that is 

being used. 


This also means that the use of hash functions with larger output 


sizes will also increase the size of the OSPFv3 packet as 
transmitted on the wire. 
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Implementation Note: [RFC2328], Appendix D specifies that the 
Authentication Trailer is not counted in the OSPF packet’s own 
Length field but is included in the packet’s IP Length field. 
Similar to this, the Authentication Trailer is not included in 
the OSPFv3 header length but is included in the IPv6é header 
payload length. 


4.6. Message Verification 


A router would determine that OSPFv3 is using an Authentication 
Trailer (AT) by examining the AT-bit in the Options field in the 
OSPFv3 header for Hello and Database Description packets. The 
specification in the Hello and Database Description options indicates 
that other OSPFv3 packets will include the Authentication Trailer. 


The AT is accessed using the OSPFv3 packet header length to access 
the data after the OSPFv3 packet and, if an LLS data block [RFC5613] 
is present, using the LLS data block length to access the data after 
the LLS data block. The L-bit in the OSPFv3 options in Hello and 
Database Description packets is examined to determine if an LLS data 
block is present. If an LLS data block is present (as specified by 
the L-bit), it is included along with the OSPFv3 Hello or Database 
Description packet in the Cryptographic Authentication computation. 


Due to the placement of the AT following the LLS data block and the 
fact that the LLS data block is included in the Cryptographic 
Authentication computation, OSPFv3 routers supporting this 
specification MUST minimally support examining the L-bit in the 
OSPFv3 options and using the length in the LLS data block to access 
the AT. It is RECOMMENDED that OSPFv3 routers supporting this 
specification fully support OSPFv3 Link-Local Signaling [RFC5613]. 


If usage of the AT, as specified herein, is configured for an OSPFv3 
link, OSPFv3 Hello and Database Description packets with the AT-bit 
clear in the options will be dropped. All OSPFv3 packet types will 
be dropped if the AT is configured for the link and the IPv6 header 
length is less than the amount necessary to include an Authentication 
Trailer. 


The receiving interface’s OSPFv3 SA is located using the SA ID in the 
received AT. If the SA is not found, or if the SA is not valid for 
reception (i.e., current time < KeyStartAccept or 

current time >= KeyStopAccept), the OSPFv3 packet is dropped. 


If the cryptographic sequence number in the AT is less than or equal 


to the last sequence number in the last OSPFv3 packet of the same 
OSPFv3 type successfully received from the neighbor, the OSPFv3 
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packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 
packets of different types may arrive out of order if they are 
prioritized as recommended in [RFC4222]. 


Authentication-algorithm-dependent processing needs to be performed, 
using the algorithm specified by the appropriate OSPFv3 SA for the 
received packet. 


Before an implementation performs any processing, it needs to save 
the values of the Authentication Data field from the Authentication 
Trailer appended to the OSPFv3 packet. 


It should then set the Authentication Data field with Apad before the 
authentication data is computed (as described in Section 4.5). The 
calculated data is compared with the received authentication data in 
the Authentication Trailer. If the two do not match, the packet MUST 
be discarded, and an error event SHOULD be logged. 


After the OSPFv3 packet has been successfully authenticated, 
implementations MUST store the 64-bit cryptographic sequence number 
for each OSPFv3 packet type received from the neighbor. The saved 
cryptographic sequence numbers will be used for replay checking for 
subsequent packets received from the neighbor. 


5. Migration and Backward Compatibility 


All OSPFv3 routers participating on a link SHOULD be migrated to 
OSPFv3 authentication at the same time. As with OSPFv2 
authentication, a mismatch in the SA ID, Authentication Type, or 
message digest will result in failure to form an adjacency. For 
multi-access links, communities of OSPFv3 routers could be migrated 
using different Interface Instance IDs. However, at least one router 
would need to form adjacencies between both the OSPFv3 routers 
including and not including the Authentication Trailer. This would 
result in sub-optimal routing as well as added complexity and is only 
recommended in cases where authentication is desired on the link and 
migrating all the routers on the link at the same time isn’t 
feasible. 


In support of uninterrupted deployment, an OSPFv3 router implementing 
this specification MAY implement a transition mode where it includes 
the Authentication Trailer in transmitted packets but does not verify 
this information in received packets. This is provided as a 
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transition aid for networks in the process of migrating to the 
authentication mechanism described in this specification. More 
specifically: 


1. OSPFv3 routers in transition mode will include the OSPFv3 
Authentication Trailer in transmitted packets and set the AT-bit 
in the Options field of transmitted Hello and Database Description 


packets. OSPFv3 routers receiving these packets and not having 
authentication configured will ignore the Authentication Trailer 
and AT-bit. 


2. OSPFv3 routers in transition mode will also calculate and set the 
OSPFv3 header checksum and the LLS data block checksum in 
transmitted packets so that they will not be dropped by OSPFv3 
routers without authentication configured. 


3. OSPFv3 routers in transition mode will authenticate received 
packets that either have the AT-bit set in the Options field for 
Hello or Database Description packets or are from a neighbor that 
previously set the AT-bit in the Options field of successfully 
authenticated Hello and Database Description packets. 


4. OSPFv3 routers in transition mode will also accept packets without 
the Options field AT-bit set in Hello and Database Description 
packets. These packets will be assumed to be from OSPFv3 routers 
without authentication configured, and they will not be 
authenticated. Additionally, the OSPFv3 header checksum and LLS 
data block checksum will be validated. 


6. Security Considerations 


This document proposes extensions to OSPFv3 that would make it more 
secure than OSPFv3 as defined in [RFC5340]. It does not provide 
confidentiality, as a routing protocol contains information that does 
not need to be kept secret. It does, however, provide means to 
authenticate the sender of packets that are of interest. It 
addresses all the security issues that have been identified in 
[RFC6039] and [RFC6506]. 


It should be noted that the authentication method described in this 
document is not being used to authenticate the specific originator of 
a packet but rather is being used to confirm that the packet has 
indeed been issued by a router that has access to the 

Authentication Key. 


Deployments SHOULD use sufficiently long and random values for the 


Authentication Key so that guessing and other cryptographic attacks 
on the key are not feasible in their environments. Furthermore, it 
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is RECOMMENDED that Authentication Keys incorporate at least 128 
pseudorandom bits to minimize the risk of such attacks. In support 
of these recommendations, management systems SHOULD support 
hexadecimal input of Authentication Keys. 


Deployments that support a transitionary state but interoperate with 
routers that do not support this authentication method may be exposed 
to unauthenticated data during the transition period. 


The mechanism described herein is not perfect and does not need to be 
perfect. Instead, this mechanism represents a significant increase 
in the effort required for an adversary to successfully attack the 
OSPFv3 protocol, while not causing undue implementation, deployment, 
or operational complexity. 


Refer to [RFC4552] for additional considerations on manual keying. 
7. IANA Considerations 


This document obsoletes RFC 6506; thus, IANA has updated the 
references in existing registries that pointed to RFC 6506 to point 
to this document. This is the only IANA action requested by this 
document. 


IANA previously allocated the AT-bit (0x000400) in the "OSPFv3 
Options (24 bits)" registry as described in Section 2.1. 


IANA previously created the "Open Shortest Path First v3 (OSPFv3) 
Authentication Trailer Options" registry. This registry includes the 
"OSPFv3 Authentication Types" registry, which defines valid values 
for the Authentication Type field in the OSPFv3 Authentication 
Trailer. The registration procedure is Standards Action [RFC5226]. 


+------------- +----------------------------------- + 

|Value | Designation 

+------------- +----------------------------------- + 

| o | Reserved 

| | | 

ieee | HMAC Cryptographic Authentication | 
2765535 Unassigned 

+------------- +----------------------------------- + 


OSPFv3 Authentication Types 
Finally, IANA previously created the "Keying and Authentication for 


Routing Protocols (KARP) Parameters" registry. This registry 
includes the "Cryptographic Protocol ID" registry, which provides 
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unique protocol-specific values for cryptographic applications, 
including but not limited to prevention of cross-protocol replay 
attacks. Values can be assigned for both native IPv4/IPv6 protocols 
and UDP/TCP protocols. The registration procedure is Standards 


Action. 
+------------- +---------------------- + 
| Value/Range | Designation 
+------------- +---------------------- + 
| o | Reserved 
| | | 
ea | OSPFv3 | 
| | | 
| 2-65535 | Unassigned | 
+------------- +---------------------- + 
Cryptographic Protocol ID 
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